Third Generation Partnership Project (3GPP)/Wireless Local Area Network (WLAN) lnterworking
Most current Wi-Fi/WLAN deployments are totally separate from mobile networks and can be seen as non-integrated from the terminal perspective. Most Operating Systems (OSs) for User Equipment devices (UEs) such as Android™ and iOS® devices, support a simple Wi-Fi offloading mechanism where a UE immediately switches all its Internet Protocol (IP) traffic to a Wi-Fi network upon detection of a suitable network with a received signal strength above a certain level. Notably, Wi-Fi and WLAN are herein used interchangeably. Henceforth, the decision to offload to a Wi-Fi network or not is referred to as access selection strategy and the term “Wi-Fi-if-coverage” is used to refer to the aforementioned strategy of selecting a Wi-Fi network whenever such a network is detected.
There are several drawbacks of the “Wi-Fi-if-coverage” strategy. A first drawback is that, although the user/UE can save previous pass codes for already accessed Wi-Fi Access Points (APs), hotspot login for previously non-accessed APs usually requires user intervention, either by entering the pass code in a Wi-Fi Connection Manager (CM) or using a web interface. The CM is software on a UE that is in charge of managing the network connections of the terminal, taking into account user preferences, operator preferences, network conditions, etc.
A second drawback is that no consideration of expected user experience is made except those considered in the UE implemented as a proprietary solution, and this can lead to a UE being handed over from a high data rate mobile network connection to a low data rate Wi-Fi connection. Even though the UE's OS or some high level software is smart enough to make the offload decisions only when a signal level on a Wi-Fi network is considerably better than a mobile network link, there can still be limitations on the backhaul of the Wi-Fi AP that may end up being a bottleneck.
A third drawback is that no consideration of the load conditions in the mobile network and the Wi-Fi network are made. As such, the UE might still be offloaded to a Wi-Fi AP that is serving several UEs while the mobile network (e.g., Long Term Evolution (LTE)) that it was previously connected to is rather unloaded.
A fourth drawback is that interruptions of on-going services can occur due to the change of IP address when the UE switches to the Wi-Fi network. For example, a user who started a Voice over IP (VoIP) call while connected to a mobile network is likely to experience a call drop when arriving home and the UE switching to the Wi-Fi network automatically. Though some applications are smart enough to handle this and survive the IP address change (e.g., Spotify®), the majority of current applications do not. This places a burden on application developers if they have to ensure service continuity.
A fifth drawback is that no consideration of the UE's mobility is made. Due to this, a fast moving UE can end up being offloaded to a Wi-Fi AP for a short duration, just to be handed over back to the mobile network. This is especially a problem in scenarios like restaurants and cafes with open Wi-Fi network, where a user walking by or even driving by the restaurant or cafe might be affected. Such ping pong between Wi-Fi and mobile networks can cause service interruptions as well as generate considerable unnecessary signaling (e.g., towards authentication servers).
Recently, Wi-Fi has been subject to increased interest from cellular network operators, and not only as an extension to fixed broadband access. The interest is mainly about using the Wi-Fi technology as an extension, or alternative, to cellular radio access network technologies to handle the always increasing wireless bandwidth demands. Cellular operators that are currently serving mobile users with, e.g., any of the 3GPP technologies (LTE, Universal Mobile Telecommunications System (UMTS)/Wideband Code Division Multiple Access (WCDMA), or Global System for Mobile Communications (GSM)) see Wi-Fi as a wireless technology that can provide good support in their regular cellular networks. The term “operator-controlled Wi-Fi” points to a Wi-Fi deployment that on some level is integrated with a cellular network operator's existing network and where 3GPP radio access networks and Wi-Fi wireless access may even be connected to the same core network and provide the same services.
There is currently quite intense activity in the area of operator-controlled Wi-Fi in several standardization organizations. In 3GPP, activities to connect Wi-Fi APs to the 3GPP-specified core network is pursued, and in Wi-Fi Alliance (WFA), activities related to certification of Wi-Fi products are undertaken, which to some extent also is driven from the need to make Wi-Fi a viable wireless technology for cellular operators to support high bandwidth offerings in their networks. The term “Wi-Fi offload” is commonly used and points towards cellular network operators seeking means to offload traffic from their cellular networks to Wi-Fi, e.g., in peak traffic hours and in situations when the cellular network for one reason or another needs to be off-loaded, e.g., to provide requested quality of service, maximize bandwidth, or simply for coverage.
Radio Access Network (RAN) Level Integration in Release 12 (Rel-12)
3GPP has specified a feature/mechanism for WLAN/3GPP radio interworking which improves operator control with respect to how a UE performs access selection and traffic steering between 3GPP and WLANs belonging to the operator or its partners. The mechanism may also be used for other, non-operator, WLANs as well, even though this is not the main target.
It is discussed that, for this mechanism, the RAN provides assistance parameters that helps the UE in access selection. RAN assistance information is composed of three main components; namely, threshold values, an Offloading Preference Indicator (OPI), and WLAN identifiers. The UE is also provided with RAN rules/policies that make use of these assistance parameters. The threshold values could be, for example, for metrics such as 3GPP signal related metrics, Reference Signal Received Power (RSRP)/Reference Signal Received Quality (RSRQ)/Received Signal Code Power (RSCP)/Energy per Chip/spectral Noise density (Ec/No), WLAN signal related metrics such as Received Channel Power Indicator (RCPI)/Received Signal Strength Indication (RSSI), WLAN load/utilization, WLAN backhaul load/capacity, etc. One example of a RAN rule that uses the threshold value could be that the UE should connect to a WLAN if the RSRP is below the signaled RSRP threshold at the same time as the WLAN RCPI is above the signaled RCPI threshold (it is also discussed that the RAN should provide thresholds for when the UE should steer traffic back from WLAN to 3GPP). The RAN rules/policies are expected to be specified in a 3GPP specification such as Technical Specification (TS) 36.304 V12.0.0 and/or TS 36.331 V12.1.0.
With the above mechanism, it is likely not wanted, or maybe not even feasible, that the UE considers any WLAN when deciding where to steer traffic. For example, it may not be feasible that the UE uses this mechanism to decide to steer traffic to a WLAN not belonging to the operator. Hence, it has been proposed that the RAN should also indicate to the UE for which WLANs the mechanism should be applied by sending WLAN identifiers.
The RAN may also provide additional parameters which are used in Access Network Discovery and Selection Function (ANDSF) policies. One proposed parameter is OPI. One possibility for OPI is that it is compared to a threshold in the ANDSF policy to trigger different actions. Another possibility is that OPI is used as a pointer to point to and select different parts of the ANDSF policy, which would then be used by the UE.
The RAN assistance parameters (i.e., thresholds, WLAN identifiers, OPI) provided by the RAN may be provided with dedicated signaling and/or broadcast signaling. Dedicated parameters can only be sent to the UE when having a valid Radio Resource Control (RRC) connection to the 3GPP RAN. A UE which has received dedicated parameters applies dedicated parameters; otherwise, the UE applies the broadcast parameters. If no RRC connection is established between the UE and the RAN, the UE cannot receive dedicated parameters.
In 3GPP, it has been agreed that ANDSF should be enhanced for Rel-12 to use the thresholds and OPI parameters that are communicated by the RAN to the UE. If enhanced ANDSF policies are provided to the UE, the UE will use the ANDSF policies instead of the RAN rules/policies (i.e., ANDSF has precedence).
Tight Integration/Aggregation between 3GPP and WLAN
Within the scope of 3GPP Release 13 (Rel-13), there has been a growing interest in realizing even tighter integration/aggregation between 3GPP and WLAN (e.g., integration/aggregation in the same way as carrier aggregation between multiple carriers in 3GPP, where the WLAN is used just as another carrier). Such an aggregation is expected to make it possible for a more optimal aggregation opportunity as compared to MultiPath Transmission Control Protocol (MPTCP), as the aggregation is performed at a lower layer (e.g., at a lower protocol layer) and as such the scheduling and flow control of the data on the WLAN and 3GPP links can be controlled by considering dynamic radio network conditions.
FIGS. 1A through 1C illustrate three different protocol options for tight integration/aggregation between 3GPP and WLAN at the Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), and Medium Access Control (MAC) levels, respectively. Note that other integration/aggregation schemes are also possible. For instance, one other example is to perform the aggregation/integration above the PDCP protocol layer. FIGS. 1A through 1C show the main principles for integration/aggregation at the PDCP level, the RLC level, and the MAC level, respectively, and additional functionality that may be needed. For example, in the PDCP level aggregation, an additional protocol layer may be used between the PDCP layer and the 802.2 Logical Link Control (LLC) layer to convey information about the UE and the radio bearer the traffic is associated with (this additional protocol layer is shown as “Glue 1” in FIGS. 2A and 2B).
Note that FIGS. 1A through 1C show the protocol stack at a UE. In the case of a standalone AP and enhanced or evolved Node B (eNB) (i.e., AP and eNB are not co-located), the protocol stack for supporting aggregation is a little bit different, as the LLC frames now have to be relayed towards the standalone eNB. FIG. 2A illustrates this for the case of PDCP level aggregation. In this case, once the LLC packet is decoded at the AP (in the uplink direction from the UE to the AP) and the AP realizes that this packet is a PDCP packet that has to be routed to an eNB, the forwarding can be performed, for example, via normal Transmission Control Protocol (TCP)/IP protocol stack. FIG. 2B shows PDCP level aggregation with a co-located/combined eNB and AP.
A study item entitled “Study on Multiple Radio Access Technology (Multi-RAT) joint coordination” has been finalized in 3GPP TSG RAN3 for 3GPP Release 13 (see 3GPP Technical Report (TR) 37.870 Release 13). The study item included investigation of potential enhancements of RAN interfaces and procedures to support the joint operation among different Radio Access Technologies (RATs), including WLAN. For the 3GPP-WLAN coordination part, it was agreed to focus on non-integrated 3GPP/WLAN nodes since integrated nodes are a matter of implementation. The study recommends the specification of an interface between Evolved Universal Terrestrial Radio Access Network (EUTRAN) and WLAN, and an architecture including such an interface is shown in FIG. 3. The interface between the WLAN AP and the eNB is referred to as an Xw interface from here onwards.
When it comes to aggregation, the Xw interface can be used not only for forwarding the aggregated data, but also for control plane signaling regarding the aggregation. Note that for the case of co-located APs and eNBs, a proprietary interface could be employed for the provision of similar functionalities.
The control plane protocol architecture between the UE and the eNB (for the case of WLAN related control signaling) and also between the eNB and the WLAN AP are illustrated in FIGS. 4 and 5. As shown in FIG. 4, the eNB can configure the settings of some of the UE's WLAN parameters and behavior via RRC signaling. On the other hand, as shown in FIG. 5, the eNB uses the XwAP application protocol of the Xw interface to configure the WLAN AP.
Carrier Aggregation (CA) and Licensed Assisted Access (LAA)
The LTE Release 10 (Rel-10) specifications have been standardized, supporting Component Carrier (CC) bandwidths up to 20 Megahertz (MHz) (which is the maximum LTE Release 8 (Rel-8) carrier bandwidth). An LTE Rel-10 operation wider than 20 MHz is possible and appears as a number of LTE CCs to a LTE Rel-10 UE. The straightforward way to obtain bandwidths wider than 20 MHz is by means of CA. CA implies that an LTE Rel-10 UE can receive multiple CCs, where each CC has, or at least has the possibility to have, the same structure as a Rel-8 carrier. CA is illustrated in FIG. 6. The Rel-10 standard supports up to five aggregated CCs where each CC is limited in the Radio Frequency (RF) specifications to have a one of six bandwidths namely 6, 15, 25, 50, 75, or 100 Resource Blocks (RBs) (corresponding to 1.4, 3 5 10 15 and 20 MHz respectively).
The number of aggregated CCs as well as the bandwidth of the individual CCs may be different for uplink and downlink. A symmetric configuration refers to the case where the number of CCs in downlink and uplink is the same whereas an asymmetric configuration refers to the case that the number of CCs is different in downlink and uplink. It is important to note that the number of CCs configured in the network may be different from the number of CCs seen by a UE. A UE may, for example, support more downlink CCs than uplink CCs, even though the network offers the same number of uplink and downlink CCs.
CCs are also referred to as cells or serving cells. More specifically, in an LTE network, the cells aggregated by a UE are denoted Primary Serving Cell (PCell) and Secondary Serving Cells (SCells). The term “serving cell” comprises both PCell and SCells. All UEs have one PCell. The cell that is a UE's PCell is UE specific and is considered “more important,” i.e. vital control signaling and other important signaling is typically handled via the PCell. Uplink control signaling is always sent on a UE's PCell. The CC configured as the PCell is the Primary CC (PCC), whereas all other CCs are SCells. The UE can send and receive data both on the PCell and the SCells. For control signaling such as scheduling commands, the control signaling can be configured to only be transmitted and received on the PCell but where the commands are also valid for the SCell, or the control signaling can be configured to be transmitted and received on both the PCell and the SCells. Regardless of the mode of operation, the UE will only need to read the broadcast channel in order to acquire system information parameters on the PCC. System information related to the Secondary Component Carriers (SCCs) may be provided to the UE in dedicated RRC messages.
During initial access, a LTE Rel-10 UE behaves similar to a LTE Rel-8 UE. However, upon successful connection to the network, a Rel-10 UE may—depending on its own capabilities and the network—be configured with additional serving cells in the uplink and downlink. Configuration is based on RRC. Due to the heavy signaling and rather slow speed of RRC signaling, it is envisioned that a UE may be configured with multiple serving cells even though not all of them are currently used.
Different deployment scenarios for CA in relation to frequency bands and the placement of cells within frequency bands is shown in FIG. 7. The different variants are i) intra-band aggregation, contiguous cells, ii) intra-band aggregation, non-contiguous cells and iii) inter-band aggregation. The different frequency bands are part of licensed spectrum.
To summarize, LTE CA supports efficient use of multiple carriers, allowing data to be sent/received over all carriers. There is support for cross-carrier scheduling avoiding the need for the UE to listen to all carrier-scheduling channels all the time. The solution relies on tight time synchronization between the carriers. The synchronization requirements impact the different deployment possibilities. It is possible to both have Intra-Digital Unit (Intra-DU) CA meaning that the PCell and all the SCell(s) are controlled by the same DU. Inter-DU CA, on the other hand, means that the PCell and SCell(s) may be controlled by different DUs.
LAA generally relates to applying LTE CA to the unlicensed spectrum. The main driver is the assumption of high availability of unlicensed spectrum globally and the use of this unlicensed spectrum for small cells. Unlicensed spectrum is used as a performance booster managed by a licensed carrier in LTE LAA. In relation to the above description about LTE CA, it can be described that the PCell is always in the licensed spectrum and that the SCell may use unlicensed bands (in addition to or without SCell(s) on licensed bands). LAA is shown in FIG. 8 and is a variant of inter-band aggregation (as shown in FIG. 7). LAA is also called LTE-LAA.
Subscriber Profile ID (SPID) for RAT/Frequency Priority
SPID is one mechanism for the core network to indicate UE-specific preferences to RAN. It is currently used, for example, for both active and idle mode mobility control of the UE.
SPID is assigned to specific subscriptions and stored in a Home Subscriber Server (HSS), as illustrated in FIG. 9. FIG. 9 more specifically illustrates SPID handling in different nodes of the cellular network. SPID is also known as RAT/Frequency Selection Priority (RFSP) index. Therefore, the SPID stored in HSS is sometimes referred to as a Subscribed RFSP index. A default value is also possible. A Mobility Management Entity (MME) receives the SPID from the HSS during the UE attach procedure and the SPID is also stored in the MME. At UE context setup, the MME forwards the SPID to the eNB, and the eNB prioritizes the RATs and carriers for both active and idle mode mobility based on the SPID. For roaming subscribers, the MME can remove or add an SPID based on International Mobile Subscriber Identity (IMSI) analysis.
The SPID value mapping in the eNB to a specific set of RATs/carriers (i.e., to be used as dedicated priority information towards the UE) are configurable as it may be operator strategy dependent. Some examples are given below in Table 1. Number 7 indicates highest priority and (No) is “forbidden.” For example, SPID value of 2 would indicate that the UE is not allowed to access LTE, and that WCDMA has higher priority than GSM.
TABLE 1SPIDLTE C1LTE C2WCDMAGSMSubscriptionDefault7654Normal1NoNo67Telephony only2NoNo76No LTE
There are different ways in which to send the SPID from the core network to the RAN. In LTE, the relevant S1AP messages used to send the SPID from the Evolved Packet Core (EPC) to the RAN are INITIAL CONTEXT SETUP REQUEST, UE CONTEXT MODIFICATION REQUEST, DOWNLINK Non-Access Stratum (NAS) TRANSPORT, and HANDOVER REQUEST. In addition, the Subscriber Profile Identity (SPID) for a RAT/frequency priority Information Element (IE) is also transferred between eNBs over the X2 interface at handover.
Handover Restriction List (HRL)
The HRL IE can be used to define roaming and access restrictions for subsequent mobility actions for which the eNB provides information about the target of the mobility action towards the UE, e.g., handover and cell change order, or for Secondary Cell Group (SCG) selection during dual connectivity operation. The HLR can contain information about serving Public Land Mobile Network (PLMN), equivalent PLMNs, forbidden tracking areas, forbidden location areas, and forbidden inter-RATs.
There are different ways in how the HRL can be sent from the core network to the RAN. In LTE, the relevant S1AP messages that can be used to send the HRL from the EPC to the RAN are INITIAL CONTEXT SETUP REQUEST, DOWNLINK NAS TRANSPORT, and HANDOVER REQUEST.